[mise-lock] chore: migrate CI to mise-action - #13
Conversation
Replace step-security/setup-beam with step-security/mise-action across ci.yaml and dev-publish.yaml, declare elixir/erlang versions in mise.toml, generate mise.lock, and gitignore actions.lock.yaml.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
mise install --locked failed in CI ("erlang@22.3.4.7 is not in the
lockfile"). Root cause: OTP 22.3.4.7 has no ubuntu-24.04 hex.pm
precompiled build and mise's core:erlang backend only ever builds it
from source for this version -- that source build fails compiling the
crypto app's OpenSSL engine against ubuntu-24.04's OpenSSL 3.x
(pkey.o link error), reproduced directly on an ubuntu:24.04 container.
Bumped erlang to 24.3.4.17 (latest OTP 24 patch, still within
Elixir 1.13's supported OTP 22-24 range and mix.exs's `elixir: "~> 1.13"`
constraint) and regenerated mise.lock. Elixir stays at 1.13.0.
Updated the CI/dev-publish workflows' OTP_VERSION/matrix values to
match (dev-publish.yaml's OTP_VERSION was also separately out of sync
at 23.3.4.7 -- aligned to the same pin).
Verified in a real ubuntu:24.04 container: mise install --locked,
mix format --check-formatted, mix compile --warnings-as-errors, and
mix test --cover (38/38 passing) all succeed against the new pin.
Claude Code fix, part of the chore/add-mise-lock fleet rollout.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…26.8.12 Pins step-security/mise-action to v4.2.4 (mise CLI 2026.8.12) and regenerates mise.lock to the versioned lockfile format mise 2026.8.11+ requires. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
HEX_ORGANIZATION_WRITE_KEY was removed and won't be restored. The `mix hex.organization auth fresha` step only exists to let `mix deps.get` fetch private packages, but every dependency in mix.exs (ex_doc, dialyxir, exvcr, jason, telemetry) is a public hex.pm package, so the auth step is unnecessary and was failing CI with an empty key.
dyl-sv
left a comment
There was a problem hiding this comment.
Reviewed all 4 commits (8f55a2b mechanical migration, 620be1c OTP bump, 67748b3 mise-action/lockfile pin refresh, b3d9bf5 remove hex.pm org auth) and live CI on the current HEAD (b3d9bf5, PR run 32959446899).
Blocking issue — missing Hex/rebar bootstrap (pattern #2). CI is currently red on both Static Checks and Unit Tests:
- https://github.com/freshaengineering/libcluster/actions/runs/32959446899/job/98148324778
- https://github.com/freshaengineering/libcluster/actions/runs/32959446899/job/98148325188
Both fail identically during mix deps.get:
Could not find Hex, which is needed to build dependency :ex_doc
** (Mix) Could not find an SCM for dependency :ex_doc from Cluster.Mixfile
Shall I install Hex? (if running non-interactively, use "mix local.hex --force") [Yn]
##[error]Process completed with exit code 1.
The old step-security/setup-beam action bootstrapped Hex/rebar automatically; step-security/mise-action does not. The static and test jobs' "Setup mise" steps in .github/workflows/ci.yaml (lines ~49 and ~118) have no mix local.hex --force / mix local.rebar --force step after them. Only the check_release job (lines 268-269) happens to still have this bootstrap (left over from before), which is why Check release passes while the two main jobs don't.
Also noted but not blocking on its own: mise.lock has two duplicate [[tools.erlang]] blocks for the same version (24.3.4.17) — one with linux-arm64/linux-x64 platforms, another with linux-arm64-musl/linux-x64-musl/macos-arm64/macos-x64/windows-x64 — which is a malformed/duplicated lockfile even though it happened not to break mise install --locked here (that step passes fine, picking the right platform). Worth cleaning up in a follow-up regen.
Also noted, non-blocking: ci.yaml's static/test/publish jobs still carry a single-value otp: [24.3.4.17] / elixir: [1.13.0] / runner-os: [ubuntu20] matrix left over from the setup-beam era; it's dead (no longer wired into the mise-action step) but harmless since it doesn't affect mise install --locked. Recommend dropping it for cleanliness in a follow-up.
Given CI is red on the current head due to the missing Hex/rebar bootstrap, requesting changes.
step-security/mise-action doesn't bootstrap Hex/rebar the way the old erlef/setup-beam action did, so mix deps.get fails immediately with "Could not find Hex, which is needed to build dependency :ex_doc" in the static and test jobs. Add mix local.hex --force / mix local.rebar --force after Setup mise in static, test, and publish (which has the same gap and would hit it too once triggered on a push to master). Addresses review feedback from dyl-sv on PR #13.
dyl-sv
left a comment
There was a problem hiding this comment.
Re-verified from scratch on the current head SHA a79d7dd.
- Commit a79d7dd ("fix: bootstrap Hex + Rebar after Setup mise") adds
mix local.hex --force/mix local.rebar --forceright after theSetup misestep in the static, test, and publish jobs of ci.yaml — this is exactly the missing bootstrap thatstep-security/mise-actiondoesn't do implicitly (unlike the oldstep-security/setup-beam). - Confirmed in the live CI logs for run 32977399180: after
Install Hex + Rebarruns, theInstall dependenciesstep logsResolving Hex dependencies...(previously it failed immediately with "Could not find Hex, which is needed to build dependency :ex_doc"),mix deps.get/mix deps.compilecomplete successfully, andmix testreports38 tests, 0 failures. gh pr checks 13shows Static Checks (Elixir 1.13.0 & OTP 24.3.4.17) and Unit Tests (Elixir 1.13.0 & OTP 24.3.4.17) both green, on the current head SHA (confirmed viagh api .../commits/a79d7dd.../check-runs).
Original blocking issue is resolved. Approving.
(Non-blocking items previously flagged — duplicate [[tools.erlang]] blocks in mise.lock and the single-value matrix leftover in ci.yaml — are still present but were never blocking; fine to leave as follow-up cleanup.)
Summary
mise.tomldeclaringelixir = "1.13.0"anderlang = "24.3.4.17". OTP22.3.4.7(the versionci.yaml's matrix originally pinned) has no ubuntu-24.04 hex.pm precompiled build and fails to build from source against ubuntu-24.04's OpenSSL 3.x, so this pins the latest OTP 24 patch instead — still within Elixir 1.13's supported OTP 22–24 range andmix.exs'selixir: "~> 1.13"constraint.step-security/setup-beamsteps in.github/workflows/ci.yaml(static, test, publish jobs) and.github/workflows/dev-publish.yamlwithstep-security/mise-action@6e96d2ffbc65c037f23c78818f2a339d6cf830f7 # v4.2.4(version: '2026.8.12'), positioned where the old setup step was (right after checkout). Both workflows'OTP_VERSION/matrix values are updated to24.3.4.17to match —dev-publish.yaml'sOTP_VERSIONhad separately drifted to23.3.4.7; the two workflows now agree.mise.lock, in the versionedlockfile_version = 1format mise 2026.8.11+ requires..github/actions.lock.yamlto.gitignoreon its own line (file remains tracked/committed as before; gitignore just prevents new local diffs from prompting re-add)..github/actions.lock.yamlviaalflow(paths/occurrences updated only, no external action pins changed)..tool-versionswas present, so nothing to remove there.Judgment calls
ci.yaml's matrix only ever contains a single OTP/Elixir pair (previouslyotp: [22.3.4.7],elixir: [1.13.0]) — this is not a multi-version compatibility matrix, so a full migration to a singlemise.tomlwas safe to proceed with.1.13.0; only the OTP/erlang version moved, driven purely by ubuntu-24.04 buildability rather than a language-version decision.Test plan
dev-publishworkflow if verifying the OTP version change is safe